Subject: Re: Updated RFC 1434 FSMs

From: [email-masked]
Date: Tue, 22 Mar 94 14:04:06 EST

Reference: Note from Gnanaprakasam Pandian on Mon, 7 Feb 94 14:06:30 PST

Gnanaprakasam, I thought I sent this out note out last month but
apparently did not. I have indicated my answers with a ===>.
Sorry for the delay.

Steve

>I would appreciate you offering explanations/answers to the following
>questions that I have.
>
>1. A TCP pipe failure is not treated as an input to the
>   state machine. I understand that all the DLCs have to be
>   closed/cleaned up and so forth.
>   Should the switch transition to HAL_TPENDING/RESTART_PENDING
>   to do a graceful shut down of all the DLCs multiplexed through
>   that TCP connection.
===>  Yes, all circuits running through the TCP connection should
===>  be halted.  The state transitions are the same as the receipt
===>  of a HALT_DL_NOACK.  I will add the loss of the TCP connection
===>  as an event in the FSMs.
>
>2. HALT_DL_NOACK SSP message gets ejected everytime the switch is
>   hit with a NETBIOS_NR/ICANREACH in
>   CONNECT/CIRCUIT_ESTABILSHED/CONNECT_PENDING.
>   Could you give an example scenario to explain this.
===>  This could happen in the event that location of the destination
===>  MAC of a TEST command is not cached and the DLSw sends out
===>  CANUREACH messages to more than one DLSw partner.  If more than
===>  one partner has connectivity to the station with the destination
===>  MAC address, the DLSw that originated the CANUREACH will receive
===>  more that one ICANREACH message in response.  The first will
===>  establish the circuit in the origin DLSw and all others will be
===>  rejected with HALT_DL_NOACKs.
>
>3. In CONNECTED state, is it possible to get a DLC_XID event
>   (which could cause an  XIDFRAME to be sent to the partner switch)
>   for non-activation XIDs?
===>   The 6611 currently does not support non-activation XIDs so they
===>   don't appear in the FSMs (no complaints yet).  However, we should
===>   probably make non-activation XID support part of the standard.
>
>4. In CONTACT_PENDING state do we have to take CONTACT message and move
>   to CONNECTED. This is nothing but a connection initiation happening
>   at both ends simultaneously and the messages crossed in flight.
===>  I assume you meant to say CONNECT_PENDING state here.  Receiving
===>  a CONTACT message while CONNECT_PENDING would mean that both
===>  end stations are sending SABMEs to each other, an SNA protocol
===>  violation.
>
>   Similary in DISCONNECT_PENDING if you get HALT_DL
>   should it move to DISCONNECTED.
===>  The circuit remains in DISCONNECT_PENDING state since a DL_HALTED
===>  will be coming in response to the HALT_DL that was sent when the
===>  circuit went to DISCONNECT_PENDING state.
>
>5. NETBIOS_AddNameQuery/NETBIOS_AddNameResponse.
>   I do not see them being used in the fsms
>   either as network or as dlc events.
>   Could you explain the  actions for these events.
===>  The NETBIOS_ANQ is used to eliminate retries of a NETBIOS
===>  ADD_NAME_QUERY over the WAN.  A NETBIOS station will send several
===>  ADD_NAME_QUERYs for a particular name when attaching to a LAN.
===>  The 6611 will send a copy of the first one to all its DLSw partners
===>  and drop the retries.  The DLSw partners will perform the retries
===>  locally.
===>
===>  The NETBIOS_ANR is used to remove any cached information derived
===>  from the ADD_NAME_QUERY it is responding to (since the NETBIOS
===>  name is already in use somewhere else).
>
>6. Do you carry RIF LF (MTU) field  in the SSP header
>   and if so which field is used for that.
===>  The RIF is not carried in the SSP header.  We have found that
===>  SNA stations tend to ignore the RIF largest frame bits and use
===>  XIDs to negotiate the largest frame size.
>
>7. Which field in the SSP header is the virtual ring number.
===>  The virtual ring number in not carried in the SSP header.
===>  Each router is configured with the number of the virtual ring
===>  it belongs to.
>
>8. For NETBIOS, SSP protocol requires to carry the whole rif in the
>   header. Will it prevent RIF termination functionality?
===>  No.  The only pieces of the RIF that are used are the broadcast
===>  indicators and the largest frame bits.  NETBIOS stations tend to
===>  respect the largest frame bits.
>
>9. TEST_CIRCUIT_REQ/TEST_CIRCUIT_RSP - what are they used for?
>
>   Is it some kind of "keepalive" signal for the circuit
>   between the switches or a "keepalive" for an end-to-end
>   session between two devices connected to the switches.
>
>   Is seems like it happens only in CONNECTED state and not
>   in CIRCUIT_ESTABLISHED state.
>   By virtue of its name it signifies that the granularity is
>   at the circuit level.
>   Do you see a problem here?
>
>   Does it carry any parameter info to do the testing at the following
>   granularity.
>       - circuit level
>       - session level
>       - ring level ; When a ring connected to any one of the switches
>          goes down it has to bring all the connections that
>         was flowing from/to the ring
===>  The TEST_CIRCUIT_REQ/TEST_CIRCUIT_RSP are creations of the 6611
===>  APPN implementation.  APPN uses these messages to ensure that
===>  a circuit is up and to measure the time required for messages to
===>  traverse the Data Link Switch.  It does not carry any parameters
===>  that control granularity.  It currently does only circuit level
===>  testing.
>
>10. I have not seen a lot of activity in the loop prevention siglet.
>    Did you enhance the SSP protocol to detect loops when you are
>    doing rif termination.
===>  I only updated the RFC 1434 FSMs to bring them up to date with
===>  the present 6611 implementation.  The FSMs produced for our
===>  DLSw standard will require updates from work done by the
===>  Loop Prevention siglet.
>
>11. In CONNECTED state I do not see DLC_ENTER_BUSY/DLC_EXIT_BUSY
>    as events from the DLCs and probably they will send out
>    ENTER_BUSY/EXIT_BUSY SSP messages.
>    I am assuming that they are not triggered by every RNR that comes
>    from the DLC but only by the buffer congestion indicators.
===>  Your assumption is correct.
>thanks
>       /pandian
>        cisco eng.

---

From: Gnanaprakasam Pandian <[email-masked]>
Date: Tue, 22 Mar 94 11:57:06 PST

Hi Steve,
Thanks for your answers and explanantions.
Could you please post the latest and greatest FSM one more time with
all the changes that have gone in so far.
This will help all of us synch up with your version.
thanks
	/pandian - cisco eng.

-- 
G. Pandian           + Gnanaprakasam Pandian      +
Cisco Systems, Inc.  + Software Engineer          +           
1525 O'Brien Drive   + Phone : (415)688-7684      +
Menlo Park,          + FAX   : (415)688-8282      +
CA 94026             + E-mail: [email-masked] +